Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Resources.Container] Add Kubernetes support #1699

Open
wants to merge 44 commits into
base: main
Choose a base branch
from

Conversation

joegoldman2
Copy link
Contributor

Fixes #1562.
Only tested manually at the moment.

For significant contributions please make sure you have completed the following items:

  • Appropriate CHANGELOG.md updated for non-trivial changes
  • Design discussion issue #
  • Changes in public API reviewed

Copy link

codecov bot commented Apr 27, 2024

Codecov Report

Attention: Patch coverage is 50.00000% with 44 lines in your changes missing coverage. Please review.

Project coverage is 73.04%. Comparing base (71655ce) to head (740efcb).
Report is 388 commits behind head on main.

Files Patch % Lines
...elemetry.Resources.Container/K8sMetadataFetcher.cs 0.00% 20 Missing ⚠️
...Telemetry.Resources.Container/ContainerDetector.cs 73.46% 13 Missing ⚠️
...esources.Container/ContainerResourceEventSource.cs 21.42% 11 Missing ⚠️
Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #1699      +/-   ##
==========================================
- Coverage   73.91%   73.04%   -0.88%     
==========================================
  Files         267      331      +64     
  Lines        9615    11986    +2371     
==========================================
+ Hits         7107     8755    +1648     
- Misses       2508     3231     +723     
Flag Coverage Δ
unittests-Exporter.Geneva 53.20% <ø> (?)
unittests-Exporter.InfluxDB 94.65% <ø> (?)
unittests-Exporter.Instana 71.24% <ø> (?)
unittests-Exporter.OneCollector 93.07% <ø> (?)
unittests-Exporter.Stackdriver 75.73% <ø> (?)
unittests-Extensions 89.01% <ø> (?)
unittests-Extensions.AWS 83.41% <ø> (?)
unittests-Extensions.Enrichment 100.00% <ø> (?)
unittests-Instrumentation.AWS 90.45% <ø> (?)
unittests-Instrumentation.AWSLambda 87.96% <ø> (?)
unittests-Instrumentation.AspNetCore 85.27% <ø> (?)
unittests-Instrumentation.ElasticsearchClient 79.87% <ø> (?)
unittests-Instrumentation.EntityFrameworkCore 55.49% <ø> (?)
unittests-Instrumentation.EventCounters 76.36% <ø> (?)
unittests-Instrumentation.GrpcNetClient 79.61% <ø> (?)
unittests-Instrumentation.Hangfire 93.58% <ø> (?)
unittests-Instrumentation.Http 82.05% <ø> (?)
unittests-Instrumentation.Process 100.00% <ø> (?)
unittests-Instrumentation.Quartz 78.94% <ø> (?)
unittests-Instrumentation.Runtime 100.00% <ø> (?)
unittests-Instrumentation.SqlClient 91.89% <ø> (?)
unittests-Instrumentation.StackExchangeRedis 67.02% <ø> (?)
unittests-Instrumentation.Wcf 78.47% <ø> (?)
unittests-PersistentStorage 65.44% <ø> (?)
unittests-Resources.AWS 74.08% <100.00%> (?)
unittests-Resources.Azure 82.83% <ø> (?)
unittests-Resources.Container 57.72% <49.42%> (?)
unittests-Resources.Gcp 72.54% <ø> (?)
unittests-Resources.Host 50.00% <ø> (?)
unittests-Resources.OperatingSystem 87.50% <ø> (?)
unittests-Resources.Process 100.00% <ø> (?)
unittests-Resources.ProcessRuntime 94.11% <ø> (?)
unittests-Sampler.AWS 87.97% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Coverage Δ
src/OpenTelemetry.Resources.AWS/AWSEKSDetector.cs 57.89% <100.00%> (ø)
...y.Resources.Container/Models/K8sContainerStatus.cs 100.00% <100.00%> (ø)
...OpenTelemetry.Resources.Container/Models/K8sPod.cs 100.00% <100.00%> (ø)
...lemetry.Resources.Container/Models/K8sPodStatus.cs 100.00% <100.00%> (ø)
...esources.Container/ContainerResourceEventSource.cs 21.42% <21.42%> (ø)
...Telemetry.Resources.Container/ContainerDetector.cs 75.94% <73.46%> (ø)
...elemetry.Resources.Container/K8sMetadataFetcher.cs 0.00% <0.00%> (ø)

... and 332 files with indirect coverage changes

@joegoldman2 joegoldman2 changed the title Add Kubernetes support in Container Resource Detector [ResourceDetectors.Container] Add Kubernetes support Apr 27, 2024
@@ -18,6 +21,13 @@ public class ContainerResourceDetector : IResourceDetector
private const string Filepath = "/proc/self/cgroup";
private const string FilepathV2 = "/proc/self/mountinfo";
private const string Hostname = "hostname";
private const string K8sServiceHostKey = "KUBERNETES_SERVICE_HOST";
private const string K8sServicePortKey = "KUBERNETES_SERVICE_PORT_HTTPS";
private const string K8sNamespaceKey = "KUBERNETES_NAMESPACE";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this environment variable and KUBERNETES_CONTAINER_NAME available in all Kubernetes environments?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From what I know, KUBERNETES_NAMESPACE and KUBERNETES_CONTAINER_NAME are not available by default in Kubernetes. The user will have to provide them using the downward API.

var @namespace = Environment.GetEnvironmentVariable(K8sNamespaceKey);
var hostname = Environment.GetEnvironmentVariable(K8sHostnameKey);
var containerName = Environment.GetEnvironmentVariable(K8sContainerNameKey);
var url = $"https://{host}:{port}/api/v1/namespaces/{@namespace}/pods/{hostname}";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the guarantee that this will be a well-formed URL?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nothing I think but in this case an exception will be thrown, catched and logged using the EventSource.

private const string K8sServicePortKey = "KUBERNETES_SERVICE_PORT_HTTPS";
private const string K8sNamespaceKey = "KUBERNETES_NAMESPACE";
private const string K8sHostnameKey = "HOSTNAME";
private const string K8sContainerNameKey = "KUBERNETES_CONTAINER_NAME";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The tricky part here - k8s doesn't have any standard variable to provide container name. It is entirely based on the user. I don't see any issues that extractor would expect it to be named "KUBERNETES_CONTAINER_NAME" - but probably it may be better to be passed by user to detector as constructor argument.
If it is passed by user, we can also report it as additional attribute.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's the same for KUBERNETES_NAMESPACE in this case, which is not standard as well. Perhaps we can let the user supply the values via the constructor but also keep automatic detection via the environment variables if they are not supplied. What do you think?

If it is passed by user, we can also report it as additional attribute.

I'm not sure that's the purpose of this detector. From my point of view, the user can already use the env variable OTEL_RESOURCE_ATTRIBUTES or implement his own detector to add this resource attribute.

@Kielek Kielek added the comp:resources.container Things related to OpenTelemetry.Resources.Container label May 6, 2024
Copy link
Contributor

This PR was marked stale due to lack of activity. It will be closed in 7 days.

@github-actions github-actions bot added the Stale label May 15, 2024
@iskiselev
Copy link
Contributor

Not stale. I'll try to finish review this week.

Copy link
Contributor

github-actions bot commented Jul 6, 2024

This PR was marked stale due to lack of activity. It will be closed in 7 days.

@github-actions github-actions bot added the Stale label Jul 6, 2024
@joegoldman2
Copy link
Contributor Author

Not stale. Waiting for @iskiselev's feedback.

Copy link
Contributor

This PR was marked stale due to lack of activity. It will be closed in 7 days.

@github-actions github-actions bot added the Stale label Jul 14, 2024
@iskiselev
Copy link
Contributor

Not stale. open-telemetry/opentelemetry-specification#4140 opened to discuss next step.
@joegoldman2, if new config environment variables will be approved, we will still need to make it configurable though factory method parameters per:
https://github.com/open-telemetry/opentelemetry-specification/blob/27bc9ffad2b386626367dd2f98d0ba2ddf35a18f/specification/configuration/sdk-environment-variables.md?plain=1#L54

@github-actions github-actions bot removed the Stale label Jul 15, 2024
@joegoldman2
Copy link
Contributor Author

Ok, so I guess the next step is to define the desired API to allow users to set the values programmatically, right?

@iskiselev
Copy link
Contributor

@joegoldman2, I already suggested API at #1699 (comment), but any would works once it allows to specify values.
I'm not sure, whether we will see any move open-telemetry/opentelemetry-specification#4140. With program API we should be able to merge this PR even without environment values support if consensus would not be reached.
Btw, do you see an option to merge it already (with @Kielek approval) or is it requires anything else? I still fully agree with @Kielek , that we should either get common agreement on environment values usage and document them - or do not use them at all.

@iskiselev
Copy link
Contributor

And looks like new environment variable would not be added any time soon: open-telemetry/opentelemetry-specification#2891 (comment). So, using API-based values may be the only option.

@joegoldman2
Copy link
Contributor Author

Thank you for the API proposal #1699 (comment). What is the procedure to review/validate a new API?

@iskiselev
Copy link
Contributor

iskiselev commented Jul 27, 2024

@joegoldman2, I actually don't know what should be the procedure to review/validate a new API. From my point of view (I'm curently codeowner for src/OpenTelemetry.Resources.Container), anything that will give a way to provide required values from code should work, as it will be in compliance with specification. As it will be isolated as arguments of AddContainerDetector method, we probably don't need any wider audience review. Alternatvely we can try to visit Tuesday meeting and seek opinions / advices there.

@iskiselev
Copy link
Contributor

BTW, we just finished validation of using k8sattributes processor on collector, and it perfectly solves the problem of resovling container.id for k8s cluster (once k8s.container.name attibute added).

Copy link
Contributor

github-actions bot commented Aug 3, 2024

This PR was marked stale due to lack of activity. It will be closed in 7 days.

@github-actions github-actions bot added the Stale label Aug 3, 2024
@github-actions github-actions bot removed the Stale label Aug 6, 2024
…urce.cs

Co-authored-by: Weihan Li <weihanli@outlook.com>
@joegoldman2
Copy link
Contributor Author

BTW, we just finished validation of using k8sattributes processor on collector, and it perfectly solves the problem of resovling container.id for k8s cluster (once k8s.container.name attibute added).

Do you have a link to the related issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
comp:resources.aws Things related to OpenTelemetry.Resources.AWS comp:resources.container Things related to OpenTelemetry.Resources.Container
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Incorrect container id reported
10 participants